_{Comment @coderabbitai help to get the list of available commands.}

[shipping-github] Merge-ready

[shipping-github] Security sanity (redacted) — quick pass on TLS-terminator Origin handling.

• Scope: Management/CORS origin checks only; allows same-host http/https skew when a reverse proxy terminates TLS (Origin https vs process http), still fail-closed on port/scheme mismatches within the same scheme.
• Boundary: Does not widen token validation or disable auth; extra origins still require explicit \corsAllowOrigins.
• Tests: \management-origin-tls\ / auth-cors regression coverage present.
• Residual risk: Misconfigured extra origins or hostile proxies that forge Origin remain the main abuse surface — unchanged from baseline.

No secrets or tokens logged in diff.

Verdict: gated

• Usefulness: Fixes Valid admin-token /api/* requests are 403'd behind a TLS-terminating reverse proxy #760 for admin-token deployments behind TLS terminators (scheme skew + tightened port matching).
• Bugs: session-cookie Origin equality still http-vs-https mismatched behind TLS — follow-up if session mode must work there.
• Security: Origin relaxation is hostname-matched https→http only; management token auth still required. Maintainer security review required (auth/CORS boundary).
• Owner/maintainer reviews: security sign-off needed.
• Bots: addressed / declined docs follow-up.
• Base / CI: PR tests green; windows suite noise unrelated.
• Gate: security review + CI clarity.

Reviewed alongside the other open security-boundary work. The defect is real and this fixes it, but I would like a narrower version before it lands.

The defect. /api/* first passes requireManagementAuth() (src/server/index.ts:391-395), then hits a separate origin gate (src/server/management-api.ts:82-85) that demands byte-for-byte equality with the process-observed http://Host origin (src/server/auth-cors.ts:91-110). Behind a TLS terminator the browser sends https://… and the proxy observes http://…, so a correctly authenticated request is refused. Confirmed on current dev.

Where the PR goes further than the report needs. It accepts a cross-scheme same-host relationship automatically, with no trusted-proxy setting. Raw callers and anything that can reach the backend directly can forge both Host and Origin — that does not bypass management auth, which runs first and compares the token in constant time (management-auth.ts:195-197), and GUI sessions still require exact origin equality plus CSRF (:198-215). So this is not an auth bypass. But it does make origin admission depend on an untrusted Host by default, for every deployment, to serve a configuration the operator already declares explicitly.

The narrower shape. The repository already has isExtraAllowedOrigin() for exactly this. Changing management admission to

!origin || origin === requestOrigin || isExtraAllowedOrigin(origin, config)

widens only to origins the operator listed in corsAllowOrigins — including the https://proxy.example.com the reporter had already configured — and makes preflight work through auth-cors.ts:134-140. Same outcome for the reported deployment, no default change for anyone else.

Negative test either way. With a remote bind and corsAllowOrigins: ["https://proxy.example.com"]: that HTTPS origin succeeds for both OPTIONS and an authenticated mutation, while https://evil.example.com and https://proxy.example.com:4443 stay 403. Session-origin and CSRF tests unchanged.

Not closing — the diagnosis is right and the fix is close. @lidge-jun @Ingwannu for the security review that MAINTAINERS.md requires here.

[shipping-github] Addressed owner feedback — narrowed management Origin admission to corsAllowOrigins only (removed automatic cross-scheme Host match).

Ready to merge @lidge-jun @Ingwannu